Add the `cfg_match!` macro by c410-f3r · Pull Request #115416 · rust-lang/rust

c410-f3r · 2023-08-31T20:35:04Z

Tracking issue: #115585

Motivation

Adds a match-like version of the cfg_if crate without a RFC for the same reasons that caused matches! to be included in the standard library.

General-purpose (not domain-specific)
Simple (the implementation is short) and useful (things can become difficult with several cfgs)
Very popular on crates.io (currently 3th in all-time downloads)
The two previous points combined make it number three in left-pad index score

#![feature(cfg_match)]

cfg_match! {
    cfg(unix) => {
        fn foo() { /* unix specific functionality */ }
    }
    cfg(target_pointer_width = "32") => {
        fn foo() { /* non-unix, 32-bit functionality */ }
    }
    _ => {
        fn foo() { /* fallback implementation */ }
    }
}

Considerations

A match-like syntax feels more natural in the sense that each macro fragment resembles an arm but I personally don't mind switching to any other desired syntax.

The lack of #[ ... ] is intended to reduce typing, nevertheless, the same reasoning described above can also be applied to this aspect.

Since blocks are intended to only contain items, anything but cfg is not expected to be supported at the current or future time.

~~Credits goes to @gnzlbg because most of the code was shamelessly copied from https://github.com/gnzlbg/match_cfg.~~
Credits goes to @alexcrichton because most of the code was shamelessly copied from https://github.com/rust-lang/cfg-if.

rustbot · 2023-08-31T20:35:10Z

r? @cuviper

(rustbot has picked a reviewer for you, use r? to override)

c410-f3r · 2023-08-31T20:37:38Z

@rustbot labels -T-libs +T-libs-api

r? libs-api

kadiwa4 · 2023-09-02T14:07:08Z

The implementation is wrong if there are more than 2 non-wildcard match arms.
Example:

match_cfg! {
    cfg(windows) => {
        fn foo() {}
    }
    cfg(unix) => {
        fn foo() {}
    }
    cfg(target_pointer_width = "64") => {
        fn foo() {}
    }
}

Fails to compile on 64-bit unix because foo is defined twice.

Also, the cfg(…) @ cfg(…) syntax used internally is not great because someone might accidentally use that, maybe use something like …, @_but_not, … or a helper macro

c410-f3r · 2023-09-02T15:03:17Z

The implementation is wrong if there are more than 2 non-wildcard match arms. Example:
match_cfg! {
    cfg(windows) => {
        fn foo() {}
    }
    cfg(unix) => {
        fn foo() {}
    }
    cfg(target_pointer_width = "64") => {
        fn foo() {}
    }
}
Fails to compile on 64-bit unix because foo is defined twice.

Also, the cfg(…) @ cfg(…) syntax used internally is not great because someone might accidentally use that, maybe use something like …, @_but_not, … or a helper macro

Well, it is a surprise... To make things more clever, the implementation will now be based on cfg_if.

Amanieu · 2023-09-05T23:49:51Z

We discussed this in the libs-api meeting and are happy to add this as an unstable feature. Please open a tracking issue for this.

There was a desire to have this supported directly by a language feature, but nobody could come up with a convincing design.

Some issues should be address before stabilization, specifically:

We should choose between the cfg_if and match_cfg syntax. Both are functionally equivalent.
- If we choose match_cfg, we should transition our existing uses of cfg_if.
We need to ensure rust-analyzer and rustfmt are able to work properly on code contained in the match arms.

tgross35 · 2023-09-05T23:59:10Z

A few small notes:

The original post should be updated, the crate is cfg_if (not if_cfg).
With that in mind, the name cfg_match could work here. Maybe better for locating via autocomplete when you type cfg?
Links:
- Existing cfg_match crate https://crates.io/crates/cfg-match
- cfg_if discussion: Tracking issue for cfg_if #59442
- IRLO discussion https://internals.rust-lang.org/t/is-cfg-if-going-to-be-pulled-into-std/13316/6

I am thinking that maybe this macro could accept single function items without wrapping in a block. This gives a more compact representation, saving an indentation level for the function body (more on par with cfg_if) plus two lines per match arm

cfg_match! {
    cfg(unix) => fn foo() {
        /* unix specific functionality */
    }
    cfg(target_pointer_width = "32") => fn foo() {
        /* non-unix, 32-bit functionality */
    }
    _ => fn foo() {
        /* fallback implementation */
    }
}

c410-f3r · 2023-09-06T01:52:12Z

I would like to express my sincere appreciation for the quick feedback, thank you @Amanieu and the participating members of the lib team.

Please open a tracking issue for this.

Done -> #115585

If we choose match_cfg, we should transition our existing uses of cfg_if.

If that will indeed be the case, then I can fulfil the task.

With that in mind, the name cfg_match could work here. Maybe better for locating via autocomplete when you type cfg?

Changed to cfg_match but IIRC, the stabilization of #79524 was halted because of conflicts with the itertools crate.

I am thinking that maybe this macro could accept single function items without wrapping in a block. This gives a more compact representation, saving an indentation level for the function body (more on par with cfg_if) plus two lines per match arm

If possible, I will do it in a following PR.

tgross35 · 2023-09-06T02:44:53Z

With that in mind, the name cfg_match could work here. Maybe better for locating via autocomplete when you type cfg?

Changed to cfg_match but IIRC, the stabilization of #79524 was halted because of conflicts with the itertools crate.

Luckily that is different - in that case, the problem is there being no way to automatically resolve a conflict between two traits when they put something with the same name in scope. Not a problem here since crates are preferred over the prelude

$ cat ../println/src/lib.rs
#[macro_export]
macro_rules! println {
    ($x:tt) => { eprintln!("haha! using my crate's println") };
}

$ cat Cargo.toml
[package]
name = "foo"
version = "0.1.0"
edition = "2021"

[dependencies]
println = { path = "../println" }

$ cat src/main.rs
use println::println;

fn main() { println!("using std's println"); }

$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.17s
     Running `target/debug/foo`
haha! using my crate's println

c410-f3r · 2023-09-06T11:13:37Z

With that in mind, the name cfg_match could work here. Maybe better for locating via autocomplete when you type cfg?

Changed to cfg_match but IIRC, the stabilization of #79524 was halted because of conflicts with the itertools crate.

Luckily that is different - in that case, the problem is there being no way to automatically resolve a conflict between two traits when they put something with the same name in scope. Not a problem here since crates are preferred over the prelude
$ cat ../println/src/lib.rs
#[macro_export]
macro_rules! println {
    ($x:tt) => { eprintln!("haha! using my crate's println") };
}

$ cat Cargo.toml
[package]
name = "foo"
version = "0.1.0"
edition = "2021"

[dependencies]
println = { path = "../println" }

$ cat src/main.rs
use println::println;

fn main() {  println!("using std's println"); }

$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.17s
     Running `target/debug/foo`
haha! using my crate's println

Glad to hear that. Thanks for investigating this scenario!

Amanieu · 2023-09-23T22:16:27Z

@bors r+

bors · 2023-09-23T22:16:29Z

📌 Commit d63959f has been approved by Amanieu

It is now in the queue for this repository.

bors · 2023-09-24T04:23:46Z

⌛ Testing commit d63959f with merge 8a6bae2...

bors · 2023-09-24T06:12:11Z

☀️ Test successful - checks-actions
Approved by: Amanieu
Pushing 8a6bae2 to master...

rust-timer · 2023-09-24T07:34:14Z

Finished benchmarking commit (8a6bae2): comparison URL.

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.6%	[0.5%, 0.7%]	4
Regressions ❌ (secondary)	0.5%	[0.5%, 0.6%]	2
Improvements ✅ (primary)	-1.3%	[-1.3%, -1.3%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.2%	[-1.3%, 0.7%]	5

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	2.5%	[2.5%, 2.5%]	1
Regressions ❌ (secondary)	3.4%	[1.7%, 5.1%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.9%	[-2.9%, -2.9%]	1
All ❌✅ (primary)	2.5%	[2.5%, 2.5%]	1

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.2%	[0.2%, 0.2%]	8
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.2%	[0.2%, 0.2%]	8

Bootstrap: 630.937s -> 629.884s (-0.17%)
Artifact size: 317.15 MiB -> 317.26 MiB (0.03%)

c410-f3r · 2023-09-24T10:11:48Z

Perf is acting stochastically IMO

rylev · 2023-09-26T18:48:53Z

Yep this is noise:

@rustbot label: +perf-regression-triaged

danielhenrymantilla · 2023-10-25T09:47:41Z

For reference, this has broken downstream crates due to name resolution errors, since for some reason the feature-gate does not prevent them:

Macro ambiguity on nightly: std::cfg_match vs crate::utils::macros::cfg_match getditto/safer_ffi#190

I will be important in the future that, whenever a new macro is added to the top-level of ::core or ::std, a crater run be involved to detect such issues and warn the developers beforehand.

c410-f3r · 2023-10-25T12:49:29Z

@danielhenrymantilla #117057 (comment) #117162

In my personal opinion, cfg_match should be renamed back to match_cfg to allow prelude support.

@traviscross

…=JonathanBrouwer stabilize `cfg_select!` *[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/149783)* tracking issue: rust-lang#115585 closes rust-lang#115585 reference PR: - rust-lang/reference#2103 # Request for Stabilization ## Summary The `cfg_select!` macro picks the expansion corresponding to the first `cfg` condition that evaluates to `true`. It simplifies complex conditional expressions. ```rust cfg_select! { unix => { fn foo() { /* unix specific functionality */ } } target_pointer_width = "32" => { fn foo() { /* non-unix, 32-bit functionality */ } } _ => { fn foo() { /* fallback implementation */ } } } let is_unix_str = cfg_select! { unix => "unix", _ => "not unix", }; println!("{is_unix_str}"); ``` ## Semantics The expansion of a `cfg_select!` call is the right-hand side of the first `cfg` rule that evaluates to true. This can be roughly expressed using this macro: ```rust macro_rules! cfg_select { ({ $($tt:tt)* }) => {{ $crate::cfg_select! { $($tt)* } }}; (_ => { $($output:tt)* }) => { $($output)* }; ( $cfg:meta => $output:tt $($( $rest:tt )+)? ) => { #[cfg($cfg)] $crate::cfg_select! { _ => $output } $( #[cfg(not($cfg))] $crate::cfg_select! { $($rest)+ } )? } } ``` The actual implementation uses a builtin macro so that `cfg_select!` can be used both in item and expression position. ## Documentation reference PR: - rust-lang/reference#2103 ## Tests The `cfg_select!` macro is already used extensively in the rust compiler codebase. It has several dedicated tests: - [`tests/ui/check-cfg/cfg-select.rs`](https://github.com/rust-lang/rust/blob/main/tests/ui/check-cfg/cfg-select.rs)tests that warnings are emitted when an unexpected `cfg` condition is used. - [`tests/ui/macros/cfg_select.rs`](https://github.com/rust-lang/rust/blob/main/tests/ui/macros/cfg_select.rs) tests that `cfg_select!` has the expected expansion, and tests that the expected syntax is accepted. ## History - rust-lang#115416 - rust-lang#117162 - rust-lang#133720 - rust-lang#135625 - rust-lang#137198 - rust-lang#138993 - rust-lang#138996 - rust-lang#143461 - rust-lang#143941 - rust-lang#145233 - rust-lang#148712 - rust-lang#149380 - rust-lang#149925 # Resolved questions # Unresolved questions The style team has decided on how to format `cfg_select!`, but this formatting has not yet been implemented. See rust-lang#144323. r? @traviscross   > [!NOTE] > # Concerns (0 active) > > - ~~[allowing-comma-after-closing-brace](rust-lang#149783 (comment) resolved in [this comment](rust-lang#149783 (comment)) > > *Managed by `@rustbot`—see [help](https://forge.rust-lang.org/triagebot/concern.html) for details.*

@traviscross

…=JonathanBrouwer stabilize `cfg_select!` *[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/149783)* tracking issue: rust-lang#115585 closes rust-lang#115585 reference PR: - rust-lang/reference#2103 # Request for Stabilization ## Summary The `cfg_select!` macro picks the expansion corresponding to the first `cfg` condition that evaluates to `true`. It simplifies complex conditional expressions. ```rust cfg_select! { unix => { fn foo() { /* unix specific functionality */ } } target_pointer_width = "32" => { fn foo() { /* non-unix, 32-bit functionality */ } } _ => { fn foo() { /* fallback implementation */ } } } let is_unix_str = cfg_select! { unix => "unix", _ => "not unix", }; println!("{is_unix_str}"); ``` ## Semantics The expansion of a `cfg_select!` call is the right-hand side of the first `cfg` rule that evaluates to true. This can be roughly expressed using this macro: ```rust macro_rules! cfg_select { ({ $($tt:tt)* }) => {{ $crate::cfg_select! { $($tt)* } }}; (_ => { $($output:tt)* }) => { $($output)* }; ( $cfg:meta => $output:tt $($( $rest:tt )+)? ) => { #[cfg($cfg)] $crate::cfg_select! { _ => $output } $( #[cfg(not($cfg))] $crate::cfg_select! { $($rest)+ } )? } } ``` The actual implementation uses a builtin macro so that `cfg_select!` can be used both in item and expression position. ## Documentation reference PR: - rust-lang/reference#2103 ## Tests The `cfg_select!` macro is already used extensively in the rust compiler codebase. It has several dedicated tests: - [`tests/ui/check-cfg/cfg-select.rs`](https://github.com/rust-lang/rust/blob/main/tests/ui/check-cfg/cfg-select.rs)tests that warnings are emitted when an unexpected `cfg` condition is used. - [`tests/ui/macros/cfg_select.rs`](https://github.com/rust-lang/rust/blob/main/tests/ui/macros/cfg_select.rs) tests that `cfg_select!` has the expected expansion, and tests that the expected syntax is accepted. ## History - rust-lang#115416 - rust-lang#117162 - rust-lang#133720 - rust-lang#135625 - rust-lang#137198 - rust-lang#138993 - rust-lang#138996 - rust-lang#143461 - rust-lang#143941 - rust-lang#145233 - rust-lang#148712 - rust-lang#149380 - rust-lang#149925 # Resolved questions # Unresolved questions The style team has decided on how to format `cfg_select!`, but this formatting has not yet been implemented. See rust-lang#144323. r? @traviscross   > [!NOTE] > # Concerns (0 active) > > - ~~[allowing-comma-after-closing-brace](rust-lang#149783 (comment) resolved in [this comment](rust-lang#149783 (comment)) > > *Managed by `@rustbot`—see [help](https://forge.rust-lang.org/triagebot/concern.html) for details.*

@traviscross

…=JonathanBrouwer stabilize `cfg_select!` *[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/149783)* tracking issue: rust-lang#115585 closes rust-lang#115585 reference PR: - rust-lang/reference#2103 # Request for Stabilization ## Summary The `cfg_select!` macro picks the expansion corresponding to the first `cfg` condition that evaluates to `true`. It simplifies complex conditional expressions. ```rust cfg_select! { unix => { fn foo() { /* unix specific functionality */ } } target_pointer_width = "32" => { fn foo() { /* non-unix, 32-bit functionality */ } } _ => { fn foo() { /* fallback implementation */ } } } let is_unix_str = cfg_select! { unix => "unix", _ => "not unix", }; println!("{is_unix_str}"); ``` ## Semantics The expansion of a `cfg_select!` call is the right-hand side of the first `cfg` rule that evaluates to true. This can be roughly expressed using this macro: ```rust macro_rules! cfg_select { ({ $($tt:tt)* }) => {{ $crate::cfg_select! { $($tt)* } }}; (_ => { $($output:tt)* }) => { $($output)* }; ( $cfg:meta => $output:tt $($( $rest:tt )+)? ) => { #[cfg($cfg)] $crate::cfg_select! { _ => $output } $( #[cfg(not($cfg))] $crate::cfg_select! { $($rest)+ } )? } } ``` The actual implementation uses a builtin macro so that `cfg_select!` can be used both in item and expression position. ## Documentation reference PR: - rust-lang/reference#2103 ## Tests The `cfg_select!` macro is already used extensively in the rust compiler codebase. It has several dedicated tests: - [`tests/ui/check-cfg/cfg-select.rs`](https://github.com/rust-lang/rust/blob/main/tests/ui/check-cfg/cfg-select.rs)tests that warnings are emitted when an unexpected `cfg` condition is used. - [`tests/ui/macros/cfg_select.rs`](https://github.com/rust-lang/rust/blob/main/tests/ui/macros/cfg_select.rs) tests that `cfg_select!` has the expected expansion, and tests that the expected syntax is accepted. ## History - rust-lang#115416 - rust-lang#117162 - rust-lang#133720 - rust-lang#135625 - rust-lang#137198 - rust-lang#138993 - rust-lang#138996 - rust-lang#143461 - rust-lang#143941 - rust-lang#145233 - rust-lang#148712 - rust-lang#149380 - rust-lang#149925 # Resolved questions # Unresolved questions The style team has decided on how to format `cfg_select!`, but this formatting has not yet been implemented. See rust-lang#144323. r? @traviscross   > [!NOTE] > # Concerns (0 active) > > - ~~[allowing-comma-after-closing-brace](rust-lang#149783 (comment) resolved in [this comment](rust-lang#149783 (comment)) > > *Managed by `@rustbot`—see [help](https://forge.rust-lang.org/triagebot/concern.html) for details.*

@traviscross

…=JonathanBrouwer stabilize `cfg_select!` *[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/149783)* tracking issue: rust-lang#115585 closes rust-lang#115585 reference PR: - rust-lang/reference#2103 # Request for Stabilization ## Summary The `cfg_select!` macro picks the expansion corresponding to the first `cfg` condition that evaluates to `true`. It simplifies complex conditional expressions. ```rust cfg_select! { unix => { fn foo() { /* unix specific functionality */ } } target_pointer_width = "32" => { fn foo() { /* non-unix, 32-bit functionality */ } } _ => { fn foo() { /* fallback implementation */ } } } let is_unix_str = cfg_select! { unix => "unix", _ => "not unix", }; println!("{is_unix_str}"); ``` ## Semantics The expansion of a `cfg_select!` call is the right-hand side of the first `cfg` rule that evaluates to true. This can be roughly expressed using this macro: ```rust macro_rules! cfg_select { ({ $($tt:tt)* }) => {{ $crate::cfg_select! { $($tt)* } }}; (_ => { $($output:tt)* }) => { $($output)* }; ( $cfg:meta => $output:tt $($( $rest:tt )+)? ) => { #[cfg($cfg)] $crate::cfg_select! { _ => $output } $( #[cfg(not($cfg))] $crate::cfg_select! { $($rest)+ } )? } } ``` The actual implementation uses a builtin macro so that `cfg_select!` can be used both in item and expression position. ## Documentation reference PR: - rust-lang/reference#2103 ## Tests The `cfg_select!` macro is already used extensively in the rust compiler codebase. It has several dedicated tests: - [`tests/ui/check-cfg/cfg-select.rs`](https://github.com/rust-lang/rust/blob/main/tests/ui/check-cfg/cfg-select.rs)tests that warnings are emitted when an unexpected `cfg` condition is used. - [`tests/ui/macros/cfg_select.rs`](https://github.com/rust-lang/rust/blob/main/tests/ui/macros/cfg_select.rs) tests that `cfg_select!` has the expected expansion, and tests that the expected syntax is accepted. ## History - rust-lang#115416 - rust-lang#117162 - rust-lang#133720 - rust-lang#135625 - rust-lang#137198 - rust-lang#138993 - rust-lang#138996 - rust-lang#143461 - rust-lang#143941 - rust-lang#145233 - rust-lang#148712 - rust-lang#149380 - rust-lang#149925 # Resolved questions # Unresolved questions The style team has decided on how to format `cfg_select!`, but this formatting has not yet been implemented. See rust-lang#144323. r? @traviscross   > [!NOTE] > # Concerns (0 active) > > - ~~[allowing-comma-after-closing-brace](rust-lang#149783 (comment) resolved in [this comment](rust-lang#149783 (comment)) > > *Managed by `@rustbot`—see [help](https://forge.rust-lang.org/triagebot/concern.html) for details.*

@traviscross

Rollup merge of #149783 - folkertdev:stabilize-cfg-select, r=JonathanBrouwer stabilize `cfg_select!` *[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/149783)* tracking issue: #115585 closes #115585 reference PR: - rust-lang/reference#2103 # Request for Stabilization ## Summary The `cfg_select!` macro picks the expansion corresponding to the first `cfg` condition that evaluates to `true`. It simplifies complex conditional expressions. ```rust cfg_select! { unix => { fn foo() { /* unix specific functionality */ } } target_pointer_width = "32" => { fn foo() { /* non-unix, 32-bit functionality */ } } _ => { fn foo() { /* fallback implementation */ } } } let is_unix_str = cfg_select! { unix => "unix", _ => "not unix", }; println!("{is_unix_str}"); ``` ## Semantics The expansion of a `cfg_select!` call is the right-hand side of the first `cfg` rule that evaluates to true. This can be roughly expressed using this macro: ```rust macro_rules! cfg_select { ({ $($tt:tt)* }) => {{ $crate::cfg_select! { $($tt)* } }}; (_ => { $($output:tt)* }) => { $($output)* }; ( $cfg:meta => $output:tt $($( $rest:tt )+)? ) => { #[cfg($cfg)] $crate::cfg_select! { _ => $output } $( #[cfg(not($cfg))] $crate::cfg_select! { $($rest)+ } )? } } ``` The actual implementation uses a builtin macro so that `cfg_select!` can be used both in item and expression position. ## Documentation reference PR: - rust-lang/reference#2103 ## Tests The `cfg_select!` macro is already used extensively in the rust compiler codebase. It has several dedicated tests: - [`tests/ui/check-cfg/cfg-select.rs`](https://github.com/rust-lang/rust/blob/main/tests/ui/check-cfg/cfg-select.rs)tests that warnings are emitted when an unexpected `cfg` condition is used. - [`tests/ui/macros/cfg_select.rs`](https://github.com/rust-lang/rust/blob/main/tests/ui/macros/cfg_select.rs) tests that `cfg_select!` has the expected expansion, and tests that the expected syntax is accepted. ## History - #115416 - #117162 - #133720 - #135625 - #137198 - #138993 - #138996 - #143461 - #143941 - #145233 - #148712 - #149380 - #149925 # Resolved questions # Unresolved questions The style team has decided on how to format `cfg_select!`, but this formatting has not yet been implemented. See #144323. r? @traviscross   > [!NOTE] > # Concerns (0 active) > > - ~~[allowing-comma-after-closing-brace](#149783 (comment) resolved in [this comment](#149783 (comment)) > > *Managed by `@rustbot`—see [help](https://forge.rust-lang.org/triagebot/concern.html) for details.*

rustbot assigned cuviper Aug 31, 2023

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Aug 31, 2023

rustbot assigned Amanieu and unassigned cuviper Aug 31, 2023

rustbot added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. and removed T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Aug 31, 2023

This comment has been minimized.

Sign in to view

c410-f3r force-pushed the match_cfg branch from 60e7774 to 5c1c7df Compare August 31, 2023 20:56

This comment has been minimized.

Sign in to view

c410-f3r force-pushed the match_cfg branch 3 times, most recently from 703b67d to 203728f Compare September 2, 2023 15:16

This comment has been minimized.

Sign in to view

c410-f3r force-pushed the match_cfg branch from 203728f to 1885429 Compare September 2, 2023 16:27

Amanieu added I-libs-api-nominated Nominated for discussion during a libs-api team meeting. and removed I-libs-api-nominated Nominated for discussion during a libs-api team meeting. labels Sep 2, 2023

c410-f3r mentioned this pull request Sep 6, 2023

Tracking issue for cfg_select (formerly cfg_match) #115585

Closed

5 tasks

c410-f3r changed the title ~~Add the match_cfg! macro~~ Add the cfg_match! macro Sep 6, 2023

c410-f3r force-pushed the match_cfg branch from 1885429 to f868bc5 Compare September 6, 2023 01:42

This comment has been minimized.

Sign in to view

Add the cfg_match! macro

d63959f

c410-f3r force-pushed the match_cfg branch from 8f6f01c to d63959f Compare September 23, 2023 17:24

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 23, 2023

bors added the merged-by-bors This PR was explicitly merged by bors. label Sep 24, 2023

bors merged commit 8a6bae2 into rust-lang:master Sep 24, 2023

rustbot added this to the 1.74.0 milestone Sep 24, 2023

rustbot added the perf-regression Performance regression. label Sep 24, 2023

rustbot added the perf-regression-triaged The performance regression has been triaged. label Sep 26, 2023

arlyon mentioned this pull request Sep 28, 2023

feature(turborepo): Go Hashing vercel/turborepo#5851

Merged

cdata mentioned this pull request Oct 13, 2023

Macro ambiguity on nightly: std::cfg_match vs crate::utils::macros::cfg_match getditto/safer_ffi#190

Closed

c410-f3r mentioned this pull request Oct 23, 2023

regression: cfg_match resolution ambiguity #117057

Closed

SC4RECOIN mentioned this pull request May 29, 2025

PROTO-178: Single extension program with compile flags (ScaledUI + No Yield) m0-foundation/solana-m-extensions#11

Merged

jieyouxu added the F-cfg_select `#![feature(cfg_select)]` label Aug 14, 2025

folkertdev mentioned this pull request Dec 8, 2025

stabilize cfg_select! #149783

Merged

Uh oh!

Comments

Conversation

c410-f3r commented Aug 31, 2023 • edited by joshtriplett Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Motivation

Considerations

Uh oh!

rustbot commented Aug 31, 2023

Uh oh!

c410-f3r commented Aug 31, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

kadiwa4 commented Sep 2, 2023

Uh oh!

c410-f3r commented Sep 2, 2023

Uh oh!

This comment has been minimized.

Amanieu commented Sep 5, 2023

Uh oh!

tgross35 commented Sep 5, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

c410-f3r commented Sep 6, 2023

Uh oh!

tgross35 commented Sep 6, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

c410-f3r commented Sep 6, 2023

Uh oh!

This comment has been minimized.

Amanieu commented Sep 23, 2023

Uh oh!

bors commented Sep 23, 2023

Uh oh!

bors commented Sep 24, 2023

Uh oh!

bors commented Sep 24, 2023

Uh oh!

rust-timer commented Sep 24, 2023

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Uh oh!

c410-f3r commented Sep 24, 2023

Uh oh!

rylev commented Sep 26, 2023

Uh oh!

danielhenrymantilla commented Oct 25, 2023

Uh oh!

c410-f3r commented Oct 25, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

14 participants

c410-f3r commented Aug 31, 2023 •

edited by joshtriplett

Loading

c410-f3r commented Aug 31, 2023 •

edited

Loading

tgross35 commented Sep 5, 2023 •

edited

Loading

tgross35 commented Sep 6, 2023 •

edited

Loading